1. Field of the Invention
The present invention relates to an API checking device and a state monitor implemented by software or hardware in devices such as mobile phones, PDAs, and PCs, and particularly relates to an API checking device disposed in a closed execution environment and a state monitor disposed in an open execution environment.
2. Description of the Related Art
Conventionally, in devices such as mobile phones, PDAs, and PCs, for example, there has been known a method for providing a so-called virtual machine monitor (VMM) which is software or hardware that can operate a plurality of operating systems (OSs) in parallel on one CPU.
In such a device, the following two execution environments can be safely isolated from each other and executed on respective OSs. In the first execution environment (hereinafter, referred to as open execution environment), programs other than trusted programs can also be executed freely or under given restriction. In the second execution environment (hereinafter, referred to as closed execution environment), predetermined processing is executed on the basis of an application program interface (API) call from the open execution environment, and only the trusted programs are executed. Here, the API call denotes a call of a function in the closed execution environment, a call for transferring and receiving data to and from the closed execution environment, etc.
Thus, the API functions provided by the closed execution environment can be called from the open execution environment. Thereby, sensitive functions and data to be protected can be used in a state where those functions and data are isolated in the closed execution environment, while free install of a program in the open execution environment is permitted (for example, U.S. Pat. No. 7,325,083).
In a technique disclosed in U.S. Pat. No. 7,325,083 mentioned above, it is assumed that an unauthorized API call is prevented by means of an access control function provided by an OS or the like disposed within the open execution environment. The access control function checks whether an API call source in the open execution environment is an authorized program. However, a malicious program such as a virus may enter the open execution environment. Additionally, there is a problem that an unauthorized API call becomes possible if the access control function is bypassed or cancelled by attack by a malicious user.
On the other hand, secure checking without interference of viruses or attack from malicious users is possible by executing: check as to whether a range of a value used as an argument of an API call or an unauthorized character is included; check on the format of transferred data; check of viruses; or the like, in the closed execution environment. However, such processing has heavy load, leading to problems such as exhaustion of a battery and deterioration of responsiveness in the mobile phones and the like.
Concerning such problems, there may be proposed a check mode set in accordance with a state of the open execution environment and that of the closed execution environment as checking means having processing load lower than that of check of the argument or the data and not being dependent only on the access control by the OS. For example, the following approach may be considered. An API checking device within the closed execution environment acquires status information on whether a program necessary for the API call (cooperation) and an unauthorized program are running in the open execution environment. When the necessary program is running and the unauthorized program is not running, the API call is permitted. Otherwise, the check mode may be set to a user warning mode for warning a user and urging the user to perform a confirmation. Here, when the program necessary for cooperation is not running, cooperation may fail, causing a failure. Therefore, measures such as warning the user in advance are needed.
However, this approach has the following problems. First, it raises operation cost to keep up with appearance of a variety of new unauthorized programs which may be continuously introduced into the open execution environment. Accordingly, another approach having lower operation cost is demanded.
Second, when the user is warned of one API call and urged to perform a confirmation, a user confirmation waiting state is kept until the user has replied to warning. During the user confirmation waiting state, other cooperation requests (API call) may be refused. However, issuance processing of a new cooperation request from the open execution environment in this state causes wasteful virtual machine switching and wasteful communication between virtual machines.
Third, introduction of checking means having lower processing load can exclude an unauthorized or unsuitable API call as a first filter. However, after such an API call passes the checking means, check having higher processing load such as check of the argument and the viruses may be executed. For that reason, delay of processing of the API call may increase to deteriorate response.
In light of such problems, an object of the present invention is to provide an API checking device and a state monitor in a device including an open execution environment and a closed execution environment, the API checking device and the state monitor capable of ensuring safety and reliability of cooperation by an API call between the open execution environment and the closed execution environment with low overhead.
To solve the above-described problem, the present invention has the following aspects. A first aspect of the present invention provides an API checking device disposed in a closed execution environment in a device including an open execution environment in which a program other than a trusted program can also be executed freely or under a given restriction; and the closed execution environment in which predetermined processing is executed on the basis of an API call that calls an application program interface from the open execution environment and only the trusted program is executed, and the API checking device includes an API check request reception unit configured to receive a determination request to request determination of whether to permit the API call within the closed execution environment from the open execution environment, a state information acquiring unit configured to acquire state information showing a state of the device, a check mode setting unit configured to set a check mode for the API call on the basis of the state information acquired by the state information acquiring unit, a determining unit configured to determine whether to permit the API call on the basis of the check mode set by the check mode setting unit, and to generate a check result of the API call, and a check result outputting unit configured to output the check result generated by the determining unit.
According to features of the present invention, in a device including an open execution environment and a closed execution environment, it is possible to provide an API checking device and a state monitor that is capable of ensuring safety and reliability of cooperation by an API call between the open execution environment and the closed execution environment with low overhead.
A Second aspect of the present invention provides a state monitor disposed in an open execution environment in a device including the open execution environment in which a program other than a trusted program can also be executed freely or under a given restriction, and the closed execution environment in which predetermined processing is executed on the basis of an API call that calls an application program interface from the open execution environment and only the trusted program is executed, and the state monitor includes a state manager configured to acquire a state of the device and maintain state information indicating the acquired state of the device, and a permission determining unit configured to determine whether to permit the API call within the closed execution environment from the open execution environment on the basis of the state information.